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I.  SYSTEM  OVERVIEW 


Traditionally,  UNIX*  has  been  a  small  system  aimed  at  experienced  computer 
users.  The  early  UNIX  queuing  systems  followed  the  basic  tools  concept  found 
throughout  UNIX  and  provided  only  basic  queuing  services  without  any  frills. 
Since  then,  UNIX  has  become  a  widely  accepted  system  servicing  a  wide  range  of 
users  and  applications.  With  wider  use  has  come  greater  demands  on  the 
software.  The  queuing  software  has  been  asked  to  provide  the  same  kinds  of 
services  found  on  "larger"  systems.  In  general,  these  requests  have  not  been 
able  to  be  satisfied  with  the  currently  released  UNIX  queuers.  The  authors, 
both  researchers  at  the  Ballistic  Research  Laboratory  (BRL),  have  undertaken 
to  develop  a  general  purpose  queuing  system  for  UNIX  as  part  of  the  continuing 
UNIX  development  project  at  BRL. 

The  Multiple  Device  Queueing  System  (MDQS)  was  designed  to  fill  in  the 
void  in  the  released  versions  of  UNIX  caused  by  the  lack  of  an  adequate  queu¬ 
ing  system.  The  MDQS  is  collection  of  programs  that  share  a  common  queue 
management  system.  There  are  "enqueuers"  that  place  items  in  the  queue. 
These  are  normally  programs  like  lpr(l)  and  at(l),  but  could  also  be  network 
servers  accepting  requests  from  another  machine.  The  "dequeuers”  are  normally 
the  programs  that  actually  handle  output  onto  the  device,  but  if  the  device  is 
not  resident  on  the  machine,  the  dequeuer  is  a  network  transfer  program  which 
will  connect  to  an  appropriate  server  process  on  a  remote  machine.  The 
dequeuers  are  analogous  to  the  UNIX  programs  lpd(8)  and  atrun(8).  Queue 
management  programs  include  the  daemon,  a  status  program,  and  a  queue  modifi¬ 
cation  program. 


II.  FEATURES 

Lack  of  a  “full  function"  queuing  system  for  UNIX  was  a  problem:  We 
wanted  a  number  of  features  that  are  common  to  any  queued  request  to  be  han¬ 
dled  by  the  same  mechanism  in  all  cases.  These  include  specification  of  start 
time,  notice  of  completion,  prioritization,  and  output  limits.  We  needed  the 
capability  for  users  to  list,  modify,  and  delete  the  queue  entries  if  neces¬ 
sary.  The  organization  of  the  queues  needed  to  allow  for  flexible  queue 
administration.  It  should  be  possible  to  have  more  than  one  device  servicing 
a  single  queue  and  likewise  more  than  one  queue  should  be  able  to  feed  a  sin¬ 
gle  device.  The  pairing  of  devices  and  queues  in  MDQS  is  table  driven  so  that 
it  can  be  reconfigured  by  simply  editing  a  file  which  MDQS  reads  at  runtime 
(not  at  compile  time!). 


‘Unix  is  a  trademark  of  Bell  Laboratories 
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III.  CONFIGURABILITY 


There  are  aeveral  factors  behind  the  design  of  the  MDQS •  The  primary 
design  criterion  Is  that  the  system  should  be  modular.  We  have  the  need  to 
queue  output  to  a  large  number  of  different  devices  on  different  machines. 
The  MDQS  will  allow  requests  to  be  queued  on  a  machine  regardless  of  whether 
the  actual  device  resides  there.  We  wanted  it  to  be  possible  to  add  and 
delete  active  queues  as  the  status  of  hardware  and  system  configurations 
changed.  Lastly,  we  didn't  want  to  haye  a  different  queuing  system  to  maln- 
i  tain  for  each  device.  This  means  less  work  for  the  systems  staff  and  one 

common  Interface  for  the  user  community  to  learn.  All  configuration  dependent 
Information  is  read  in  at  runtime  by  those  MDQS  programs  that  need  to  know, 
enabling  us  to  have  transportable  binaries  among  homogeneous  machines  which 
greatly  simplifies  queue  management. 


IV.  FUNCTIONAL  EXAMPLE 

An  example  of  the  use  of  the  MDQS  will  be  helpful  in  showing  some  of  the 
capabilities  of  the  system.  A  typical  user  might  start  the  day  by  submitting 
3  requests  to  the  print  queue  to  be  printed  on  8x11  paper.  He  later  finds  out 
that  the  computer  room  is  out  of  8x11  paper.  One  of  his  printouts  is  needed 
for  a  meeting,  so  he  decides  to  print  it  on  15x11  instead.  He  does  a  queue 
status  command  to  find  his  print  requests  Ids.  Using  the  queue  modify  com¬ 
mand,  he  changes  the  forms  on  his  second  request  to  15x11  and  asks  that  he  be 
notified  Mien  the  request  is  completed.  Twenty  minutes  later  he  receives  an 
electronic  message  from  the  queue  daemon  announcing  that  his  second  print 
request  has  completed. 

Later  that  day,  the  user  queues  2  "batch”  jobs  to  be  run  after  midnight 
and  again  does  a  queue  status  command.  The  two  8x11  prints  (id-1,3)  are  still 
there,  and  the  new  batch  joba  (id-4,5)  are  now  also  shown.  Finally,  before  he 
leaves  for  the  night,  he  decides  to  start  running  the  first  batch  job  with  the 
hope  that  it  will  be  done  by  the  time  he  is  finished  with  dinner.  Using  the 
qmodlfy  command  he  changes  the  start  time  of  the  job  to  the  current  time. 
That  evening  he  logs  on  to  get  his  mail  and  finds  his  first  job  has  completed 
successfully. 

The  operators  for  the  system  could  also  issue  the  commands  demonstrated 
above  but  if  they  wanted  to  access  other  than  their  own  requests,  they  would 
have  to  specify  the  user  as  well  as  the  request  id.  Operators  also  need  to  be 
able  to  inform  MDQS  of  changes  in  the  queuing  system  (e.g.,  changes  in  paper 
type,  enabling  of  a  second  printer).  To  make  these  changes,  the  operator  just 
edits  the  MDQS  configuration  file.  The  queue  daemon  detects  the  changes  and 
modifies  its  internal  tables  accordingly. 


/q  (755) 


(700) 


/qcontrol  (777)  /qdata  (777) 

Figure  1:  MDQS  Directory  Hierarchy 
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